home *** CD-ROM | disk | FTP | other *** search
/ The 640 MEG Shareware Studio 2 / The 640 Meg Shareware Studio CD-ROM Volume II (Data Express)(1993).ISO / info / vl5_184.zip / VL5-184.TXT
Internet Message Format  |  1992-11-20  |  88KB

  1. From lehigh.edu!virus-l Fri Nov 20 00:25:41 1992
  2. Date: Wed, 18 Nov 1992 16:10:33 -0500
  3. Message-Id: <9211182009.AA20731@barnabas.cert.org>
  4. Comment: Virus Discussion List
  5. Originator: virus-l@lehigh.edu
  6. Errors-To: krvw@cert.org
  7. Reply-To: <virus-l@lehigh.edu>
  8. Sender: virus-l@lehigh.edu
  9. Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
  10. From: "Kenneth R. van Wyk" <krvw@cert.org>
  11. To:   Multiple recipients of list <virus-l@lehigh.edu>
  12. Subject: VIRUS-L Digest V5 #184
  13. Status: R
  14.  
  15. VIRUS-L Digest   Wednesday, 18 Nov 1992    Volume 5 : Issue 184
  16.  
  17. Today's Topics:
  18.  
  19. VIRUS-L/comp.virus Frequently Asked Questions (FAQ) list
  20.  
  21. VIRUS-L is a moderated, digested mail forum for discussing computer
  22. virus issues; comp.virus is a non-digested Usenet counterpart.
  23. Discussions are not limited to any one hardware/software platform -
  24. diversity is welcomed.  Contributions should be relevant, concise,
  25. polite, etc.  (The complete set of posting guidelines is available by
  26. FTP on cert.sei.cmu.edu or upon request.) Please sign submissions with
  27. your real name.  Send contributions to VIRUS-L@LEHIGH.EDU.
  28. Information on accessing anti-virus, documentation, and back-issue
  29. archives is distributed periodically on the list.  A FAQ (Frequently
  30. Asked Questions) document and all of the back-issues are available by
  31. anonymous FTP on cert.org (192.88.209.5).  Administrative mail
  32. (comments, suggestions, and so forth) should be sent to me at:
  33. <krvw@CERT.ORG>.
  34.  
  35.    Ken van Wyk
  36.  
  37. ----------------------------------------------------------------------
  38.  
  39. Date:    Wed, 18 Nov 92 11:29:05 -0500
  40. From:    "Kenneth R. van Wyk" <krvw@cert.org>
  41. Subject: VIRUS-L/comp.virus Frequently Asked Questions (FAQ) list
  42.  
  43.            Frequently Asked Questions on VIRUS-L/comp.virus
  44.              Last Updated: 18 November 1992, 7:45 AM EST
  45.  
  46. ====================
  47. = Preface Section: =
  48. ====================
  49.  
  50. This document is intended to answer the most Frequently Asked
  51. Questions (FAQs) about computer viruses.  As you can see, there are
  52. many of them!  If you are desperately seeking help after recently
  53. discovering what appears to be a virus on your computer, consider
  54. skimming through sections A and B to learn the essential jargon, then
  55. concentrate on section C.
  56.  
  57. If you may have found a new virus, or are not quite sure if some file
  58. or boot sector is infected, it is important to understand the protocol
  59. for raising such questions, e.g. to avoid asking questions that can be
  60. answered in this document, and to avoid sending "live" viruses except
  61. to someone who is responsible (and even then in a safe form!).
  62.  
  63. Above all, remember the time to really worry about viruses is BEFORE
  64. your computer gets one!
  65.  
  66. The FAQ is a dynamic document, which changes as people's questions
  67. change.  Contributions are gratefully accepted -- please e-mail them
  68. to me at krvw@cert.org.  The most recent copy of this FAQ will always
  69. be available on the VIRUS-L/comp.virus archives, including the
  70. anonymous FTP on cert.org (192.88.209.5) in the file:
  71. pub/virus-l/FAQ.virus-l
  72.  
  73. Ken van Wyk, moderator VIRUS-L/comp.virus
  74.  
  75. Primary contributors (in alphabetical order):
  76.     Mark Aitchison <phys169@csc.canterbury.ac.nz>
  77.     Vaughan Bell <vaughan@computing-department.poly-south-west.ac.uk>
  78.     Matt Bishop <matt.bishop@dartmouth.edu>
  79.     Vesselin Bontchev <bontchev@fbihh.informatik.uni-hamburg.de>
  80.     Olivier M.J. Crepin-Leblond <umeeb37@vaxa.cc.ic.ac.uk>
  81.     David Chess <chess@watson.ibm.com>
  82.     John-David Childs <con_jdc@lewis.umt.edu>
  83.     Nick FitzGerald <cctr132@csc.canterbury.ac.nz>
  84.     Claude Bersano-Hayes <hayes@urvax.urich.edu>
  85.     John Kida <jhk@washington.ssds.COM>
  86.     Donald G. Peters <Peters@Dockmaster.NCSC.Mil>
  87.     A. Padgett Peterson <padgett%tccslr.dnet@mmc.com>
  88.     Y. Radai <radai@hujivms.huji.ac.il>
  89.     Rob Slade <rslade@sfu.ca>
  90.     Gene Spafford <spaf@cs.purdue.edu>
  91.     Otto Stolz <rzotto@nyx.uni-konstanz.de>
  92.  
  93. ====================
  94.  
  95.              Questions answered in this document
  96.  
  97. Section A:   Sources of Information and Anti-viral Software
  98.              (Where can I find HELP..!)
  99.  
  100. A1)  What is VIRUS-L/comp.virus?
  101. A2)  What is the difference between VIRUS-L and comp.virus?
  102. A3)  How do I get onto VIRUS-L/comp.virus?
  103. A4)  What are the guidelines for VIRUS-L?
  104. A5)  How can I get back-issues of VIRUS-L?
  105. A6)  What is VALERT-L?
  106. A7)  What are the known viruses, their names, major symptoms and
  107.      possible cures?
  108. A8)  Where can I get free or shareware anti-virus programs?
  109. A9)  Where can I get more information on viruses, etc.?
  110.  
  111.  
  112. Section B:   Definitions
  113.              (What is ...?)
  114.  
  115. B1)  What are computer viruses (and why should I worry about them)?
  116. B2)  What is a Trojan Horse?
  117. B3)  What are the main types of PC viruses?
  118. B4)  What is a stealth virus?
  119. B5)  What is a polymorphic virus?
  120. B6)  What are fast and slow infectors?
  121. B7)  What is a sparse infector?
  122. B8)  What is a companion virus?
  123. B9)  What is an armored virus?
  124. B10) Miscellaneous Jargon and Abbreviations
  125.  
  126.  
  127. Section C:   Virus Detection
  128.              (Is my computer infected?  What do I do?)
  129.  
  130. C1)  What are the symptoms and indications of a virus infection?
  131. C2)  What steps should be taken in diagnosing and identifying viruses?
  132. C3)  What is the best way to remove a virus?
  133. C4)  What does the <insert name here> virus do?
  134. C5)  What are "false positives" and "false negatives"?
  135. C6)  Could an anti-viral program itself be infected?
  136. C7)  Where can I get a virus scanner for my Unix system?
  137. C8)  Why does an antiviral scanner report an infection only sometimes?
  138. C9)  Is my disk infected with the Stoned virus?
  139. C10) I think I have detected a new virus; what do I do?
  140. C11) CHKDSK reports 639K (or less) total memory on my system; am I
  141.      infected?
  142. C12) I have an infinite loop of sub-directories on my hard drive; am I
  143.      infected?
  144.  
  145.  
  146. Section D:   Protection Plans
  147.              (What should I do to prepare against viruses?)
  148.  
  149. D1)  What is the best protection policy for my computer?
  150. D2)  Is it possible to protect a computer system with only software?
  151. D3)  Is it possible to write-protect the hard disk with only software?
  152. D4)  What can be done with hardware protection?
  153. D5)  Will setting DOS file attributes to READ ONLY protect them from
  154.      viruses?
  155. D6)  Will password/access control systems protect my files from
  156.      viruses?
  157. D7)  Will the protection systems in DR DOS work against viruses?
  158. D8)  Will a write-protect tab on a floppy disk stop viruses?
  159. D9)  Do local area networks (LANs) help to stop viruses or do they
  160.      facilitate their spread?
  161. D10) What is the proper way to make backups?
  162.  
  163.  
  164. Section E:    Facts and Fibs about computer viruses
  165.               (Can a virus...?)
  166.  
  167. E1)  Can boot sector viruses infect non-bootable floppy disks?
  168. E2)  Can a virus hide in a PC's CMOS memory?
  169. E3)  Can a virus hide in Extended or in Expanded RAM?
  170. E4)  Can a virus hide in Upper Memory or in High Memory?
  171. E5)  Can a virus infect data files?
  172. E6)  Can viruses spread from one type of computer to another?
  173. E7)  Can DOS viruses run on non-DOS machines (e.g. Mac, Amiga)?
  174. E8)  Can mainframe computers be susceptible to computer viruses?
  175. E9)  Some people say that disinfecting files is a bad idea. Is that
  176.      true?
  177. E10) Can I avoid viruses by avoiding shareware/free software/games?
  178. E11) Can I contract a virus on my PC by performing a "DIR" of an
  179.      infected floppy disk?
  180. E12) Is there any risk in copying data files from an infected floppy
  181.      disk to a clean PC's hard disk?
  182. E13) Can a DOS virus survive and spread on an OS/2 system using the
  183.      HPFS file system?
  184. E14) Under OS/2 2.0, could a virus infected DOS session infect another
  185.      DOS session?
  186. E15) Can normal DOS viruses work under MS Windows?
  187.  
  188.  
  189. Section F:    Miscellaneous Questions
  190.               (I was just wondering...)
  191.  
  192. F1) How many viruses are there?
  193. F2) How do viruses spread so quickly?
  194. F3) What is the plural of "virus"?  "Viruses" or "viri" or "virii" or...
  195. F4) When reporting a virus infection (and looking for assistance), what
  196.     information should be included?
  197. F5) How often should we upgrade our anti-virus tools to minimize
  198.     software and labor costs and maximize our protection?
  199.  
  200.  
  201. Section G:    Specific Virus and Anti-viral software Questions...
  202.  
  203. G1) I was infected by the Jerusalem virus and disinfected the infected
  204.     files with my favorite anti-virus program.  However, Wordperfect
  205.     and some other programs still refuse to work.  Why?
  206. G2) I was told that the Stoned virus displays the text "Your PC is now
  207.     Stoned" at boot time.  I have been infected by this virus several
  208.     times, but have never seen the message.  Why?
  209. G3) I was infected by both Stoned and Michelangelo.  Why has my
  210.     computer became unbootable?  And why, each time I run my favorite
  211.     scanner, does it find one of the viruses and say that it is
  212.     removed, but when I run it again, it says that the virus is still
  213.     there?
  214.  
  215.  
  216. ================================================================
  217. = Section A.   Sources of Information and Anti-viral Software. =
  218. ================================================================
  219.  
  220. A1) What is VIRUS-L/comp.virus?
  221.  
  222. It is a discussion forum with a focus on computer virus issues.  More
  223. specifically, VIRUS-L is an electronic mailing list and comp.virus is
  224. a USENET newsgroup.  Both groups are moderated; all submissions arederator for
  225. possible inclusion in the group.  For more
  226. information, including a copy of the posting guidelines, see the file
  227. virus-l.README, available by anonymous FTP on cert.org in the
  228. pub/virus-l directory.  (FTP is the Internet File Transfer Protocol,
  229. and is described in more detail in the monthly VIRUS-L/comp.virus
  230. archive postings - see below.)
  231.  
  232. Note that there have been, from time to time, other USENET
  233. cross-postings of VIRUS-L, including the bit.listserv.virus-l.  These
  234. groups are generally set up by individual site maintainers and are not
  235. as globally accessible as VIRUS-L and comp.virus.
  236.  
  237.  
  238. A2) What is the difference between VIRUS-L and comp.virus?
  239.  
  240. As mentioned above, VIRUS-L is a mailing list and comp.virus is a
  241. newsgroup.  In addition, VIRUS-L is distributed in digest format (with
  242. multiple e-mail postings in one large digest) and comp.virus is
  243. distributed as individual news postings.  However, the content of the
  244. two groups is identical.
  245.  
  246.  
  247. A3) How do I get onto VIRUS-L/comp.virus?
  248.  
  249. Send e-mail to LISTSERV@LEHIGH.EDU stating: "SUB VIRUS-L your-name".
  250. To "subscribe" to comp.virus, simply use your favorite USENET news
  251. reader to read the group (assuming that your site receives USENET
  252. news).
  253.  
  254.  
  255. A4) What are the guidelines for VIRUS-L?
  256.  
  257. The list of posting guidelines is available by anonymous FTP on
  258. cert.org.  See the file pub/virus-l/virus-l.README for the most recent
  259. copy.  In general, however, the moderator requires that discussions
  260. are polite and non-commercial.  (Objective postings of product
  261. availability, product reviews, etc., are fine, but commercial
  262. advertisements are not.)  Also, requests for viruses (binary or
  263. disassembly) are not allowed.  Technical discussions are strongly
  264. encouraged, however, within reason.
  265.  
  266.  
  267. A5) How can I get back-issues of VIRUS-L?
  268.  
  269. VIRUS-L/comp.virus includes a series of archive sites that carry all
  270. the back issues of VIRUS-L, as well as public anti-virus software (for
  271. various computers) and documents.  The back-issues date back to the
  272. group's inception, 21 April 1988.  The list of archive sites is
  273. updated monthly and distributed to the group; it includes a complete
  274. listing of the sites, what they carry, access instructions, as well as
  275. information on how to access FTP sites by e-mail.  The anonymous FTP
  276. archive at cert.org carries all of the VIRUS-L back issues.  See the
  277. file pub/virus-l/README for more information on the cert.org archive
  278. site.
  279.  
  280.  
  281. A6) What is VALERT-L?
  282.  
  283. VALERT-L is a sister group to VIRUS-L, but is intended for virus
  284. alerts and warnings only -- NO DISCUSSIONS.  There is no direct USENET
  285. counterpart to VALERT-L; it is a mailing list only.  All VALERT-L
  286. postings are re-distributed to VIRUS-L/comp.virus later.  This group
  287. is also moderated, but on a much higher priority than VIRUS-L.  The
  288. group is monitored during business hours (East Coast, U.S.A.,
  289. GMT-5/GMT-4); high priority off-hour postings can be made by
  290. submitting to the group and then telephoning the CERT/CC hotline at +1
  291. 412 268 7090 -- instruct the person answering the hotline to call or
  292. page Ken van Wyk.
  293.  
  294. Subscriptions to VALERT-L are handled identically to VIRUS-L --
  295. contact the LISTSERV.
  296.  
  297.  
  298. A7) What are the known viruses, their names, major symptoms and
  299.     possible cures?
  300.  
  301. First of all, the reader must be aware that there is no universally
  302. accepted naming convention for viruses, nor is there any standard
  303. means of testing.  As a consequence nearly ALL viral information is
  304. highly subjective and subject to interpretation and dispute.
  305.  
  306. There are several major sources of information on specific viruses.
  307. Probably the biggest one is Patricia Hoffman's hypertext VSUM.  It
  308. describes only DOS viruses, but almost all of them which are known
  309. at any given time.  Unfortunately, it is regarded by many in the field
  310. as being inaccurate, so we do not advise people to rely solely on it.
  311. It can be downloaded from most major archive sites except SIMTEL20.
  312.  
  313. The second one is the Computer Virus Catalog, published by the Virus
  314. Test Center in Hamburg.  It contains a highly technical description of
  315. computer viruses for several platforms: DOS, Mac, Amiga, Atari ST,
  316. Unix.  Unfortunately, the DOS section is quite incomplete.  The CVC
  317. is available for anonymous FTP from ftp.informatik.uni-hamburg.de
  318. (IP=134.100.4.42), directory pub/virus/texts/catalog.  (A copy of the
  319. CVC is also available by anonymous FTP on cert.org in the
  320. pub/virus-l/docs/vtc directory.)
  321.  
  322. A third source of information is the monthly Virus Bulletin, published
  323. in the UK.  Among other things, it gives detailed technical
  324. information on viruses (see also A9 below).  Unfortunately, it is very
  325. expensive (the subscription price is $395 per year).  US subscriptions
  326. can be obtained by calling 203-431-8720 or writing to 590 Danbury
  327. Road, Ridgefield, CT 06877; for European subscriptions, the number is
  328. +44-235-555139 and the address is: The Quadrant, Abingdon, OX14 3YS,
  329. England.
  330.  
  331. A fourth good source of information on DOS viruses is the "Computer
  332. Viruses" report of the National/International Computer Security
  333. Association.  This is updated regularly, and is fairly complete.
  334. Copies cost approximately $75, and can be ordered by calling +1-
  335. 202-244-7875.  ICSA/NCSA also publishes the monthly "Virus News and
  336. Reviews" and other publications.
  337.  
  338. Another source of information is the documentation of Dr. Solomon's
  339. Anti-Virus ToolKit.  It is more complete than the CVC list, just as
  340. accurate (if not more), but lists only DOS viruses.  However, it is
  341. not available electronically; you must buy his anti-virus package and
  342. the virus information is part of the documentation.
  343.  
  344. Yet another source of information is "Virus News International",
  345. published by S & S International.  And, while not entirely virus-
  346. related, "Computers & Security" provides information on many
  347. aspects of computer security, including viruses.
  348.  
  349. The best source of information available on Apple Macintosh viruses is
  350. the on-line documentation provided with the freeware Disinfectant
  351. program by John Norstad.  This is available at most Mac archive sites.
  352.  
  353.  
  354. A8) Where can I get free or shareware anti-virus programs?
  355.  
  356. The VIRUS-L/comp.virus archive sites carry publicly distributable
  357. anti-virus software products.  See a recent listing of the archive
  358. sites (or ask the moderator for a recent listing) for more information
  359. on these sites.
  360.  
  361. Many freeware/shareware anti-virus programs for DOS are available via
  362. anonymous FTP on WSMR-SIMTEL20.ARMY.MIL (192.88.110.20), in the
  363. directory PD1:<MSDOS.TROJAN-PRO>.  Note that the SIMTEL20 archives
  364. are also "mirrored" at many other anonymous FTP sites, including
  365. oak.oakland.edu (141.210.10.117, pub/msdos/trojan-pro),
  366. wuarchive.wustl.edu (128.252.135.4, /mirrors/msdos/trojan-pro),
  367. and nic.funet.fi (128.214.6.100, /pub/msdos/utilities/trojan-pro).
  368. They can also be obtained via e-mail in uuencoded form from various
  369. TRICKLE sites, especially in Europe.
  370.  
  371. Likewise, Macintosh anti-virus programs can be found on SIMTEL20 in
  372. the PD3:<MACINTOSH.VIRUS> directory.
  373.  
  374. A list of many anti-viral programs, incl. commercial products and one
  375. person's rating of them, can be obtained by anonymous ftp from
  376. cert.org (192.88.209.5) in pub/virus-l/docs/reviews as file
  377. slade.quickref.rvw.
  378.  
  379.  
  380. A9)  Where can I get more information on viruses, etc.?
  381.  
  382. There are four excellent books on computer viruses available that
  383. should cover most of the introductory and technical questions you
  384. might have:
  385.  
  386.     * "Computers Under Attack: Intruders, Worms and Viruses," edited by
  387.    Peter J. Denning, ACM Press/Addison-Wesley, 1990.  This is a book of
  388.    collected readings that discuss computer viruses, computer worms,
  389.    break-ins, legal and social aspects, and many other items related to
  390.    computer security and malicious software.  A very solid, readable
  391.    collection that doesn't require a highly-technical background.
  392.    Price: $20.50.
  393.  
  394.      * "Rogue Programs: Viruses, Worms and Trojan Horses," edited by
  395.    Lance J. Hoffman, Van Nostrand Reinhold, 1990.  This is a book of
  396.    collected readings describing in detail how viruses work, where they
  397.    come from, what they do, etc.  It also has material on worms, trojan
  398.    horse programs, and other malicious software programs.  This book
  399.    focuses more on mechanism and relatively less on social aspects than
  400.    does the Denning book; however, there is an excellent piece by Anne
  401.    Branscomb that covers the legal aspects.  Price: $32.95.
  402.  
  403.      * "A Pathology of Computer Viruses," by David Ferbrache,
  404.    Springer-Verlag, 1992.  This is a recent, in-depth book on the
  405.    history, operation, and effects of computer viruses.  It is one of the
  406.    most complete books on the subject, with an extensive history section,
  407.    a section on Macintosh viruses, network worms, and Unix viruses (if
  408.    they were to exist).
  409.  
  410.      * "A Short Course on Computer Viruses", by Dr. Fred B. Cohen, ASP
  411.    Press, 1990.  This book is by a well-known pioneer in virus research,
  412.    who has also written dozens of technical papers on the subject.  The
  413.    book can be obtained by writing to ASP Press, P.O. Box 81270,
  414.    Pittsburgh, PA 15217.  Price: $24.00.
  415.  
  416. A somewhat dated, but still useful, high-level description of viruses,
  417. suitable for a complete novice without extensive computer background
  418. is in "Computer Viruses: Dealing with Electronic Vandalism and
  419. Programmed Threats," by Eugene H. Spafford, Kathleen A. Heaphy, and
  420. David J. Ferbrache, ADAPSO (Arlington VA), 1989.  ADAPSO is a
  421. computer industry service organization and not a publisher, so the
  422. book cannot be found in bookstores; copies can be obtained directly
  423. from ADAPSO @ +1 703-522-5055).  There is a discount for ADAPSO
  424. members, educators, and law enforcement personnel.  Many people have
  425. indicated they find this a very understandable reference; portions of
  426. it have been reprinted many other places, including Denning &
  427. Hoffman's books (above).
  428.  
  429. It is also worth consulting various publications such as _Computers &
  430. Security_ (which, while not restricted to viruses, contains many of
  431. Cohen's papers) and the _Virus Bulletin_ (published in the UK; its
  432. technical articles are considered good, although there has been much
  433. criticism in VIRUS-L of some of its product evaluations).
  434.  
  435.  
  436. ======================================================
  437. = Section B.   Definitions and General Information   =
  438. ======================================================
  439.  
  440. B1) What are computer viruses (and why should I worry about them)?
  441.  
  442. According to Fred Cohen's well-known definition, a COMPUTER VIRUS is a
  443. computer program that can infect other computer programs by modifying
  444. them in such a way as to include a (possibly evolved) copy of itself.
  445. Note that a program does not have to perform outright damage (such as
  446. deleting or corrupting files) in order to to be called a "virus".
  447. However, Cohen uses the terms within his definition (e.g. "program"
  448. and "modify") a bit differently from the way most anti-virus
  449. researchers use them, and classifies as viruses some things which most
  450. of us would not consider viruses.
  451.  
  452. Many people use the term loosely to cover any sort of program that
  453. tries to hide its (malicious) function and tries to spread onto as
  454. many computers as possible.  (See the definition of "Trojan".)  Be
  455. aware that what constitutes a "program" for a virus to infect may
  456. include a lot more than is at first obvious - don't assume too much
  457. about what a virus can or can't do!
  458.  
  459. These software "pranks" are very serious; they are spreading faster
  460. than they are being stopped, and even the least harmful of viruses
  461. could be fatal.  For example, a virus that stops your computer and
  462. displays a message, in the context of a hospital life-support
  463. computer, could be fatal.  Even those who created the viruses could
  464. not stop them if they wanted to; it requires a concerted effort from
  465. computer users to be "virus-aware", rather than the ignorance and
  466. ambivalence that have allowed them to grow to such a problem.
  467.  
  468.  
  469. B2) What is a Trojan Horse?
  470.  
  471. A TROJAN HORSE is a program that does something undocumented which the
  472. programmer intended, but that the user would not approve of if he knew
  473. about it.  According to some people, a virus is a particular case of a
  474. Trojan Horse, namely one which is able to spread to other programs
  475. (i.e., it turns them into Trojans too).  According to others, a virus
  476. that does not do any deliberate damage (other than merely replicating)
  477. is not a Trojan.  Finally, despite the definitions, many people use
  478. the term "Trojan" to refer only to a *non-replicating* malicious
  479. program, so that the set of Trojans and the set of viruses are
  480. disjoint.
  481.  
  482.  
  483. B3) What are the main types of PC viruses?
  484.  
  485. Generally, there are two main classes of viruses.  The first class
  486. consists of the FILE INFECTORS which attach themselves to ordinary
  487. program files.  These usually infect arbitrary .COM and/or .EXE
  488. programs, though some can infect any program for which execution is
  489. requested, such as .SYS, .OVL, .PRG, & .MNU files.
  490.  
  491. File infectors can be either DIRECT ACTION or RESIDENT.  A direct-
  492. action virus selects one or more other programs to infect each time
  493. the program which contains it is executed.  A resident virus hides
  494. itself somewhere in memory the first time an infected program is
  495. executed, and thereafter infects other programs when *they* are
  496. executed (as in the case of the Jerusalem) or when certain other
  497. conditions are fulfilled.  The Vienna is an example of a direct-action
  498. virus.  Most other viruses are resident.
  499.  
  500. The second category is SYSTEM or BOOT-RECORD INFECTORS: those viruses
  501. which infect executable code found in certain system areas on a disk
  502. which are not ordinary files.   On DOS systems, there are ordinary
  503. boot-sector viruses, which infect only the DOS boot sector, and MBR
  504. viruses which infect the Master Boot Record on fixed disks and the DOS
  505. boot sector on diskettes.  Examples include Brain, Stoned, Empire,
  506. Azusa, and Michelangelo.  Such viruses are always resident viruses.
  507.  
  508. Finally, a few viruses are able to infect both (the Tequila virus is
  509. one example).  These are often called "MULTI-PARTITE" viruses, though
  510. there has been criticism of this name; another name is "BOOT-AND-FILE"
  511. virus.
  512.  
  513. FILE SYSTEM or CLUSTER viruses (e.g. Dir-II) are those which modify
  514. directory table entries so that the virus is loaded and executed
  515. before the desired program is.  Note that the program itself is not
  516. physically altered, only the directory entry is.  Some consider these
  517. infectors to be a third category of viruses, while others consider
  518. them to be a sub-category of the file infectors.
  519.  
  520.  
  521. B4) What is a stealth virus?
  522.  
  523. A STEALTH virus is one which hides the modifications it has made in
  524. the file or boot record, usually by monitoring the system functions
  525. used by programs to read files or physical blocks from storage media,
  526. and forging the results of such system functions so that programs
  527. which try to read these areas see the original uninfected form of the
  528. file instead of the actual infected form. Thus the viral modifications
  529. go undetected by anti-viral programs.  However, in order to do this,
  530. the virus must be resident in memory when the anti-viral program is
  531. executed.
  532.  
  533. Example: The very first DOS virus, Brain, a boot-sector infector,
  534. monitors physical disk I/O and re-directs any attempt to read a
  535. Brain-infected boot sector to the disk area where the original boot
  536. sector is stored.  The next viruses to use this technique were the
  537. file infectors Number of the Beast and Frodo (= 4096 = 4K).
  538.  
  539. Countermeasures: A "clean" system is needed so that no virus is
  540. present to distort the results.  Thus the system should be built from
  541. a trusted, clean master copy before any virus-checking is attempted;
  542. this is "The Golden Rule of the Trade."  With DOS, (1) boot from
  543. original DOS diskettes (i.e. DOS Startup/Program diskettes from a
  544. major vendor that have been write-protected since their creation);
  545. (2) use only tools from original diskettes until virus-checking has
  546. completed.
  547.  
  548.  
  549. B5) What is a polymorphic virus?
  550.  
  551. A POLYMORPHIC virus is one which produces varied (yet fully
  552. operational) copies of itself, in the hope that virus scanners (see
  553. D1) will not be able to detect all instances of the virus.
  554.  
  555. One method to evade signature-driven virus scanners is self-encryption
  556. with a variable key; however these viruses (e.g. Cascade) are not
  557. termed "polymorphic," as their decryption code is always the same and
  558. thus can be used as a virus signature even by the simplest, signature-
  559. driven virus scanners (unless another virus or program uses the
  560. identical decryption routine).
  561.  
  562. One method to make a polymorphic virus is to choose among a variety of
  563. different encryption schemes requiring different decryption routines:
  564. only one of these routines would be plainly visible in any instance of
  565. the virus (e.g. the Whale virus).  A signature-driven virus scanner
  566. would have to exploit several signatures (one for each possible
  567. encryption method) to reliably identify a virus of this kind.
  568.  
  569. A more sophisticated polymorphic virus (e.g. V2P6) will vary the
  570. sequence of instructions in its copies by interspersing it with
  571. "noise" instructions (e.g. a No Operation instruction, or an
  572. instruction to load a currently unused register with an arbitrary
  573. value), by interchanging mutually independent instructions, or even by
  574. using various instruction sequences with identical net effects (e.g.
  575. Subtract A from A, and Move 0 to A).  A simple-minded, signature-based
  576. virus scanner would not be able to reliably identify this sort of
  577. virus; rather, a sophisticated "scanning engine" has to be constructed
  578. after thorough research into the particular virus.
  579.  
  580. The most sophisticated form of polymorphism discovered so far is the
  581. MtE "Mutation Engine" written by the Bulgarian virus writer who calls
  582. himself the "Dark Avenger".  It comes in the form of an object module.
  583. Any virus can be made polymorphic by adding certain calls to the
  584. assembler source code and linking to the mutation-engine and
  585. random-number-generator modules.
  586.  
  587. The advent of polymorphic viruses has rendered virus-scanning an ever
  588. more difficult and expensive endeavor; adding more and more search
  589. strings to simple scanners will not adequately deal with these
  590. viruses.
  591.  
  592.  
  593. B6) What are fast and slow infectors?
  594.  
  595. A typical file infector (such as the Jerusalem) copies itself to
  596. memory when a program infected by it is executed, and then infects
  597. other programs when they are executed.
  598.  
  599. A FAST infector is a virus which, when it is active in memory, infects
  600. not only programs which are executed, but even those which are merely
  601. opened.  The result is that if such a virus is in memory, running a
  602. scanner or integrity checker can result in all (or at least many)
  603. programs becoming infected all at once.  Examples are the Dark Avenger
  604. and the Frodo viruses.
  605.  
  606. The term "SLOW infector" is sometimes used for a virus which, if it is
  607. active in memory, infects only files as they are modified (or
  608. created).  The purpose is to fool people who use integrity checkers
  609. into thinking that the modification reported by the integrity checker
  610. is due solely to legitimate reasons.  An example is the Darth Vader
  611. virus.
  612.  
  613.  
  614. B7) What is a sparse infector?
  615.  
  616. The term "SPARSE infector" is sometimes given to a virus which
  617. infects only occasionally, e.g. every 10th executed file, or only
  618. files whose lengths fall within a narrow range, etc.  By infecting
  619. less often, such viruses try to minimize the probability of being
  620. discovered by the user.
  621.  
  622.  
  623. B8) What is a companion virus?
  624.  
  625. A COMPANION virus is one which, instead of modifying an existing file,
  626. creates a new program which (unknown to the user) gets executed by the
  627. command-line interpreter instead of the intended program.  (On exit,
  628. the new program executes the original program so that things will
  629. appear normal.)  The only way this has been done so far is by creating
  630. an infected .COM file with the same name as an existing .EXE file.
  631. Note that those integrity checkers which look only for *modifications*
  632. in *existing* files will fail to detect such viruses.
  633.  
  634. (Note that not all researchers consider this type of malicious code
  635. to be a virus, since it does not modify existing files.)
  636.  
  637.  
  638. B9) What is an armored virus?
  639.  
  640. An ARMORED virus is one which uses special tricks to make the tracing,
  641. disassembling and understanding of their code more difficult.  A good
  642. example is the Whale virus.
  643.  
  644.  
  645. B10) Miscellaneous Jargon and Abbreviations
  646.  
  647. BSI = Boot Sector Infector: a virus which takes control when the
  648.  computer attempts to boot (as opposed to a file infector).
  649.  
  650. CMOS = Complementary Metal Oxide Semiconductor: A memory area that is
  651.  used in AT and higher class PCs for storage of system information.
  652.  CMOS is battery backed RAM (see below), originally used to maintain
  653.  date and time information while the PC was turned off.  CMOS memory
  654.  is not in the normal CPU address space and cannot be executed.  While
  655.  a virus may place data in the CMOS or may corrupt it, a virus cannot
  656.  hide there.
  657.  
  658. DOS = Disk Operating System.  We use the term "DOS" to mean any of the
  659.  MS-DOS, PC-DOS, or DR DOS systems for PCs and compatibles, even
  660.  though there are operating systems called "DOS" on other (unrelated)
  661.  machines.
  662.  
  663. MBR = Master Boot Record: the first Absolute sector (track 0, head 0,
  664.  sector 1) on a PC hard disk, that usually contains the partition table
  665.  (but on some PCs may simply contain a boot sector).  This is not the
  666.  same as the first DOS sector (Logical sector 0).
  667.  
  668. RAM = Random Access Memory: the place programs are loaded into in
  669.  order to execute; the significance for viruses is that, to be active,
  670.  they must grab some of this for themselves.  However, some virus
  671.  scanners may declare that a virus is active simply when it is found
  672.  in RAM, even though it might be simply left over in a buffer area of
  673.  RAM rather than truly being active.
  674.  
  675. TOM = Top Of Memory: the end of conventional memory, an architectural
  676.  design limit at the 640K mark on most PCs.  Some early PCs may not
  677.  be fully populated, but the amount of memory is always a multiple of
  678.  64K.  A boot-record virus on a PC typically resides just below this
  679.  mark and changes the value which will be reported for the TOM to the
  680.  location of the beginning of the virus so that it won't get
  681.  overwritten.  Checking this value for changes can help detect a
  682.  virus, but there are also legitimate reasons why it may change (see
  683.  C11).  A very few PCs with unusual memory managers/settings may
  684.  report in excess of 640K.
  685.  
  686. TSR = Terminate but Stay Resident: these are PC programs that stay in
  687.  memory while you continue to use the computer for other purposes;
  688.  they include pop-up utilities, network software, and the great
  689.  majority of viruses.  These can often be seen using utilities such as
  690.  MEM, MAPMEM, PMAP, F-MMAP and INFOPLUS.
  691.  
  692.  
  693. =================================
  694. = Section C.    Virus Detection =
  695. =================================
  696.  
  697. C1)  What are the symptoms and indications of a virus infection?
  698.  
  699. Viruses try to spread as much as possible before they deliver their
  700. "payload", but there can be symptoms of virus infection before this,
  701. and it is important to use this opportunity to spot and eradicate the
  702. virus before any destruction.
  703.  
  704. There are various kinds of symptoms which some virus authors have
  705. written into their programs, such as messages, music and graphical
  706. displays.  However, the main indications are changes in file sizes and
  707. contents, changing of interrupt vectors or the reassignment of other
  708. system resources.  The unaccounted use of RAM or a reduction in the
  709. amount known to be in the machine are important indicators.  The
  710. examination of the code is valuable to the trained eye, but even the
  711. novice can often spot the gross differences between a valid boot
  712. sector and an infected one.  However, these symptoms, along with
  713. longer disk activity and strange behavior from the hardware, can also
  714. be caused by genuine software, by harmless "prank" programs, or by
  715. hardware faults.
  716.  
  717. The only foolproof way to determine that a virus is present is for an
  718. expert to analyze the assembly code contained in all programs and
  719. system areas, but this is usually impracticable.  Virus scanners go
  720. some way towards that by looking in that code for known viruses; some
  721. will even try to use heuristic means to spot viral code, but this is
  722. not always reliable.  It is wise to arm yourself with the latest
  723. anti-viral software, but also to pay close attention to your system;
  724. look particularly for any change in the memory map or configuration as
  725. soon as you start the computer.  For users of DOS 5.0, the MEM program
  726. with the /C switch is very handy for this.  If you have DRDOS, use MEM
  727. with the /A switch; if you have an earlier version, use CHKDSK or the
  728. commonly-available PMAP or MAPMEM utilities.  You don't have to know
  729. what all the numbers mean, only that they change.  Mac users have
  730. "info" options that give some indication of memory use, but may need
  731. ResEdit for more detail.
  732.  
  733.  
  734. C2)  What steps should be taken in diagnosing and identifying viruses?
  735.  
  736. Most of the time, a virus scanner program will take care of that for
  737. you.  (Remember, though, that scanning programs must be kept up to
  738. date.  Also remember that different scanner authors may call the same
  739. virus by different names.  If you want to identify a virus in order to
  740. ask for help, it is best to run at least two scanners on it and, when
  741. asking, say which scanners, and what versions, gave the names.)  To
  742. help identify problems early, run it on new programs and diskettes;
  743. when an integrity checker reports a mismatch, when a generic
  744. monitoring program sounds an alarm; or when you receive an updated
  745. version of a scanner (or a different scanner than the one you have
  746. been using).  However, because of the time required, it is not
  747. generally advisable to insert into your AUTOEXEC.BAT file a command to
  748. run a scanner on an entire hard disk on every boot.
  749.  
  750. If you run into an alarm that the scanner doesn't identify, or
  751. doesn't properly clean up for you, first verify that the version that
  752. you are using is the most recent, and then get in touch with one of
  753. the reputable antivirus researchers, who may ask you to send a copy
  754. of the infected file to him.  See also question C10.
  755.  
  756.  
  757. C3) What is the best way to remove a virus?
  758.  
  759. In order that downtime be short and losses low, do the minimum that
  760. you must to restore the system to a normal state, starting with
  761. booting the system from a clean diskette.  It is very unlikely that
  762. you need to low-level reformat the hard disk!
  763.  
  764. If backups of the infected files are available and appropriate care
  765. was taken when making the backups (see D10), this is the safest
  766. solution, even though it requires a lot of work if many files are
  767. involved.
  768.  
  769. More commonly, a disinfecting program is used.  If the virus is a boot
  770. sector infector, you can continue using the computer with relative
  771. safety if you boot it from a clean system diskette, but it is wise to
  772. go through all your diskettes removing infection, since sooner or
  773. later you may be careless and leave a diskette in the machine when it
  774. reboots.  Boot sector infections on PCs can be cured by a two-step
  775. approach of replacing the MBR (on the hard disk), either by using a
  776. backup or by the FDISK/MBR command (from DOS 5 and up), then using the
  777. SYS command to replace the DOS boot sector.
  778.  
  779.  
  780. C4) What does the <insert name here> virus do?
  781.  
  782. If an anti-virus program has detected a virus on your computer, don't
  783. rush to post a question to this list asking what it does.  First, it
  784. might be a false positive alert (especially if the virus is found only
  785. in one file), and second, some viruses are extremely common, so the
  786. question "What does the Stoned virus do?" or "What does the Jerusalem
  787. virus do?" is asked here repeatedly.  While this list is monitored by
  788. several anti-virus experts, they get tired of perpetually answering
  789. the same questions over and over again.  In any case, if you really
  790. need to know what a particular virus does (as opposed to knowing
  791. enough to get rid of it), you will need a longer treatise than could
  792. be given to you here.
  793.  
  794. For example, the Stoned virus replaces the disk's boot record with its
  795. own, relocating the original to a sector on the disk that may (or may
  796. not) occur in an unused portion of the root directory of a DOS
  797. diskette; when active, it sits in an area a few kilobytes below the
  798. top of memory.  All this description could apply to a number of common
  799. viruses; but the important points of where the original boot sector
  800. goes - and what effect that has on networking software, non-DOS
  801. partitions, and so on are all major questions in themselves.
  802.  
  803. Therefore, it is better if you first try to answer your question
  804. yourself.  There are several sources of information about the known
  805. computer viruses, so please consult one of them before requesting
  806. information publicly.  Chances are that your virus is rather well known
  807. and that it is already described in detail in at least one of these
  808. sources.  (See the answer to question A7, for instance.)
  809.  
  810.  
  811. C5) What are "false positives" and "false negatives"?
  812.  
  813. A FALSE POSITIVE (or Type-I) error is one in which the anti-viral
  814. software claims that a given file is infected by a virus when in
  815. reality the file is clean.  A FALSE NEGATIVE (or Type-II) error is one
  816. in which the software fails to indicate that an infected file is
  817. infected.  Clearly false negatives are more serious than false
  818. positives, although both are undesirable.
  819.  
  820. It has been proven by Dr. Fred Cohen that every virus detector must
  821. have either false positives or false negatives or both.  This is
  822. expressed by saying that detection of viruses is UNDECIDABLE.
  823. However his theorem does not preclude a program which has no false
  824. negatives and *very few* false positives (e.g. if the only false
  825. positives are those due to the file containing viral code which is
  826. never actually executed, so that technically we do not have a virus).
  827.  
  828. In the case of virus scanners, false positives are rare, but they can
  829. arise if the scan string chosen for a given virus is also present in
  830. some benign programs because the string was not well chosen.  False
  831. negatives are more common with virus scanners because scanners will
  832. miss a completely new or a heavily modified virus.
  833.  
  834. One other serious problem could occur: A positive that is misdiagnosed
  835. (e.g., a scanner that detects the Empire virus in a boot record but
  836. reports it as the Stoned).  In the case of a boot sector infector, use
  837. of a Stoned specific "cure" to recover from the Empire could result in
  838. an unreadable disk or loss of extended partitions.  Similarly,
  839. sometimes "generic" recovery can result in unusable files, unless a
  840. check is made (e.g. by comparing checksums) that the recovered file is
  841. identical to the original file.  Some more recent products store
  842. information about the original programs to allow verification of
  843. recovery processes.
  844.  
  845.  
  846. C6) Could an anti-viral program itself be infected?
  847.  
  848. Yes, so it is important to obtain this software from good sources, and
  849. to trust results only after running scanners from a "clean" system.
  850. But there are situations where a scanner appears to be infected when
  851. it isn't.
  852.  
  853. Most antiviral programs try very hard to identify only viral
  854. infections, but sometimes they give false alarms.  If two different
  855. antiviral programs are both of the "scanner" type, they will contain
  856. "signature strings" to identify viral infections.  If the strings are
  857. not "encrypted", then they will be identified as a virus by another
  858. scanner type program.  Also, if the scanner does not remove the
  859. strings from memory after they are run, then another scanner may
  860. detect the virus string "in memory".
  861.  
  862. Some "change detection" type antiviral programs add a bit of code or
  863. data to a program when "protecting" it.  This might be detected by
  864. another "change detector" as a change to a program, and therefore
  865. suspicious.
  866.  
  867. It is good practice to use more than one antiviral program.  Do be
  868. aware, however, that antiviral programs, by their nature, may confuse
  869. each other.
  870.  
  871.  
  872. C7) Where can I get a virus scanner for my Unix system?
  873.  
  874. Basically, you shouldn't bother scanning for Unix viruses at this
  875. point in time.  Although it is possible to write Unix-based viruses,
  876. we have yet to see any instance of a non-experimental virus in that
  877. environment.  Someone with sufficient knowledge and access to write an
  878. effective virus would be more likely to conduct other activities than
  879. virus-writing.  Furthermore, the typical form of software sharing in
  880. an Unix environment would not support virus spread.
  881.  
  882. This answer is not meant to imply that viruses are impossible, or that
  883. there aren't security problems in a typical Unix environment -- there
  884. are.  However, true viruses are highly unlikely and would corrupt file
  885. and/or memory integrity.  For more information on Unix security, see
  886. the book "Practical Unix Security" by Garfinkel and Spafford, O'Reilly
  887. & Associates, 1991 (it can be ordered via e-mail from nuts@ora.com).
  888.  
  889. However, there are special cases for which scanning Unix systems for
  890. non-Unix viruses does make sense.  For example, a Unix system which is
  891. acting as a file server (e.g., PC-NFS) for PC systems is quite capable
  892. of containing PC file infecting viruses that are a danger to PC clients.
  893. Note that, in this example, the UNIX system would be scanned for PC
  894. viruses, not UNIX viruses.
  895.  
  896. Another example is in the case of a 386/486 PC system running Unix,
  897. since this system is still vulnerable to infection by MBR infectors
  898. such as Stoned and Michelangelo, which are operating system
  899. independent.  (Note that an infection on such a Unix PC system would
  900. probably result in disabling the Unix disk partition(s) from booting.)
  901.  
  902. In addition, a file integrity checker (to detect unauthorized changes
  903. in executable files) on Unix systems is a very good idea.  (One free
  904. program which can do this test, as well as other tests, is the COPS
  905. package, available by anonymous FTP on cert.org.)  Unauthorized
  906. file changes on Unix systems are very common, although they usually
  907. are not due to virus activity.
  908.  
  909.  
  910. C8) Why does my anti-viral scanner report an infection only sometimes?
  911.  
  912. There are circumstances where part of a virus exists in RAM without
  913. being active:  If your scanner reports a virus in memory only
  914. occasionally, it could be due to the operating system buffering disk
  915. reads, keeping disk contents that include a virus in memory
  916. (harmlessly), in which case it should also find it on disk.  Or after
  917. running another scanner, there may be scan strings left (again
  918. harmlessly) in memory.  This is sometimes called a "ghost positive"
  919. alert.
  920.  
  921.  
  922. C9) Is my disk infected with the Stoned virus?
  923.  
  924. Of course the answer to this, and many similar questions, is to obtain
  925. a good virus detector.  There are many to choose from, including ones
  926. that will scan diskettes automatically as you use them.  Remember to
  927. check all diskettes, even non-system ("data") diskettes.
  928.  
  929. It is possible, if you have an urgent need to check a system when
  930. you don't have any anti-viral tools, to boot from a clean system
  931. diskette, and use the CHKDSK method (mentioned in C1) to see if it is
  932. in memory, then look at the boot sector with a disk editor.  Usually
  933. the first few bytes will indicate the characteristic far jump of the
  934. Stoned virus; however, you could be looking at a perfectly good disk
  935. that has been "innoculated" against the virus, or at a diskette that
  936. seems safe but contains a totally different type of virus.
  937.  
  938.  
  939. C10) I think I have detected a new virus; what do I do?
  940.  
  941. Whenever there is doubt over a virus, you should obtain the latest
  942. versions of several (not just one) major virus scanners. Some scanning
  943. programs now use "heuristic" methods (F-PROT, CHECKOUT and SCANBOOT
  944. are examples), and "activity monitoring" programs can report a disk or
  945. file as being possibly infected when it is in fact perfectly safe
  946. (odd, perhaps, but not infected).  If no string-matching scan finds a
  947. virus, but a heuristic program does (or there are other reasons to
  948. suspect the file, e.g., change in size of files) then it is possible
  949. that you have found a new virus, although the chances are probably
  950. greater that it is an odd-but-okay disk or file.  Start by looking in
  951. recent VIRUS-L postings about "known" false positives, then contact
  952. the author of the anti-virus software that reports it as virus-like;
  953. the documentation for the software may have a section explaining what
  954. to do if you think you have found a new virus.  Consider using the
  955. BootID or Checkout programs to calculate the "hashcode" of a diskette
  956. in the case of boot sector infectors, rather than send a complete
  957. diskette or "live" virus until requested.
  958.  
  959.  
  960. C11) CHKDSK reports 639K (or less) total memory on my system; am I
  961.      infected?
  962.  
  963. If CHKDSK displays 639K for the total memory instead of 640K (655,360
  964. bytes) - so that you are missing only 1K - then it is probably due to
  965. reasons other than a virus since there are very few viruses which take
  966. only 1K from total memory.  Legitimate reasons for a deficiency of 1K
  967. include:
  968.  
  969. 1) A PS/2 computer.  IBM PS/2 computers reserve 1K of conventional
  970.   RAM for an Extended BIOS Data Area, i.e. for additional data storage
  971.   required by its BIOS.
  972. 2) A computer with American Megatrends Inc. (AMI) BIOS, which is set
  973.   up (with the built-in CMOS setup program) in such a way that the BIOS
  974.   uses the upper 1K of memory for its internal variables.  (It can be
  975.   instructed to use lower memory instead.)
  976. 3) A SCSI controller.
  977. 4) The DiskSecure program.
  978. 5) Mouse buffers for older Compaqs.
  979.  
  980. If, on the other hand, you are missing 2K or more from the 640K, 512K,
  981. or whatever the conventional memory normally is for your PC, the
  982. chances are greater that you have a boot-record virus (e.g. Stoned,
  983. Michelangelo), although even in this case there may be legitimate
  984. reasons for the missing memory:
  985.  
  986. 1) Many access control programs for preventing booting from a floppy.
  987. 2) H/P Vectra computers.
  988. 3) Some special BIOSes which use memory (e.g.) for a built-in calendar
  989.   and/or calculator.
  990.  
  991. However, these are only rough guides.  In order to be more certain
  992. whether the missing memory is due to a virus, you should:
  993. (1) run several virus detectors;
  994. (2) look for a change in total memory every now and then;
  995. (3) compare the total memory size with that obtained when cold booting
  996.   from a "clean" system diskette.  The latter should show the normal
  997.   amount of total memory for your configuration.
  998.  
  999. Note: in all cases, CHKDSK should be run without software such as
  1000. MS-Windows or DesqView loaded, since GUIs seem to be able to open DOS
  1001. boxes only on whole K boundaries (some seem to be even coarser); thus
  1002. CHKDSK run from a DOS box may report unrepresentative values.
  1003.  
  1004. Note also that some machines have only 512K or 256K instead of 640K of
  1005. conventional memory.
  1006.  
  1007.  
  1008. C12) I have an infinite loop of sub-directories on my hard drive; am I
  1009.      infected?
  1010.  
  1011. Probably not.  This happens now and then, when something sets the
  1012. "cluster number" field of some subdirectory the same cluster as an
  1013. upper-level (usually the root) directory.  The /F parameter of CHKDSK,
  1014. and any of various popular utility programs, should be able to fix
  1015. this, usually by removing the offending directory.  *Don't* erase any
  1016. of the "replicated" files in the odd directory, since that will erase
  1017. the "copy" in the root as well (it's really not a copy at all; just a
  1018. second pointer to the same file).
  1019.  
  1020.  
  1021. ===================================
  1022. = Section D.    Protection plans  =
  1023. ===================================
  1024.  
  1025. D1) What is the best protection policy for my computer?
  1026.  
  1027. There is no "best" anti-virus policy.  In particular, there is no
  1028. program that can magically protect you against all viruses.  But you
  1029. can design an anti-virus protection strategy based on multiple layers
  1030. of defense.  There are three main kinds of anti-viral software, plus
  1031. several other means of protection (such as hardware write-protect
  1032. methods).
  1033.  
  1034. 1) GENERIC MONITORING programs.  These try to prevent viral activity
  1035.    before it happens, such as attempts to write to another executable,
  1036.    reformat the disk, etc.
  1037.    Examples: SECURE and FluShot+ (PC), and GateKeeper (Macintosh).
  1038.  
  1039. 2) SCANNERS.  Most look for known virus strings (byte sequences which
  1040.    occur in known viruses, but hopefully not in legitimate software) or
  1041.    patterns, but a few use heuristic techniques to recognize viral
  1042.    code.  A scanner may be designed to examine specified disks or
  1043.    files on demand, or it may be resident, examining each program
  1044.    which is about to be executed.  Most scanners also include virus
  1045.    removers.
  1046.    Examples: FindViru in Dr Solomon's Anti-Virus Toolkit, FRISK's
  1047.    F-Prot, McAfee's VIRUSCAN (all PC), Disinfectant (Macintosh).
  1048.    Resident scanners: McAfee's V-Shield, and VIRSTOP.
  1049.    Heuristic scanners: the Analyse module in FRISK's F-PROT package,
  1050.    and SCANBOOT.
  1051.  
  1052. 3) INTEGRITY CHECKERS or MODIFICATION DETECTORS.  These compute a
  1053.    small "checksum" or "hash value" (usually CRC or cryptographic)
  1054.    for files when they are presumably uninfected, and later compare
  1055.    newly calculated values with the original ones to see if the files
  1056.    have been modified.  This catches unknown viruses as well as known
  1057.    ones and thus provides *generic* detection.  On the other hand,
  1058.    modifications can also be due to reasons other than viruses.
  1059.    Usually, it is up to the user to decide which modifications are
  1060.    intentional and which might be due to viruses, although a few
  1061.    products give the user help in making this decision.  As in the
  1062.    case of scanners, integrity checkers may be called to checksum
  1063.    entire disks or specified files on demand, or they may be resident,
  1064.    checking each program which is about to be executed (the latter is
  1065.    sometimes called an INTEGRITY SHELL).  A third implementation is as
  1066.    a SELF-TEST, i.e. the checksumming code is attached to each
  1067.    executable file so that it checks itself just before execution.
  1068.    Examples: Fred Cohen's ASP Integrity Toolkit (commercial), and
  1069.    Integrity Master and VDS (shareware), all for the PC.
  1070.  
  1071. 3a) A few modification detectors come with GENERIC DISINFECTION.  I.e.,
  1072.    sufficient information is saved for each file that it can be
  1073.    restored to its original state in the case of the great majority
  1074.    of viral infections, even if the virus is unknown.
  1075.    Examples: V-Analyst 3 (BRM Technologies, Israel), marketed in the
  1076.    US as Untouchable (by Fifth Generation), and the VGUARD module of
  1077.    V-care.
  1078.  
  1079. Of course, only a few examples of each type have been given.  All of
  1080. them can find their place in the protection against computer viruses,
  1081. but you should appreciate the limitations of each method, along with
  1082. system-supplied security measures that may or may not be helpful in
  1083. defeating viruses.  Ideally, you would arrange a combination of
  1084. methods that cover the loopholes between them.
  1085.  
  1086. A typical PC installation might include a protection system on the
  1087. hard disk's MBR to protect against viruses at load time (ideally this
  1088. would be hardware or in BIOS, but software methods such as DiskSecure
  1089. and PanSoft's Immunise are pretty good).  This would be followed by
  1090. resident virus detectors loaded as part of the machine's startup
  1091. (CONFIG.SYS or AUTOEXEC.BAT), such as FluShot+ and/or VirStop together
  1092. with ScanBoot.  A scanner such as F-Prot or McAfee's SCAN could be
  1093. put into AUTOEXEC.BAT to look for viruses as you start up, but this
  1094. may be a problem if you have a large disk to check (or don't reboot
  1095. often enough).  Most importantly, new files should be scanned as they
  1096. arrive on the system.  If your system has DR DOS installed, you should
  1097. use the PASSWORD command to write-protect all system executables and
  1098. utilities.  If you have Stacker or SuperStore, you can get some
  1099. improved security from these compressed drives, but also a risk that
  1100. those viruses stupid enough to directly write to the disk could do
  1101. much more damage than normal; using a software write-protect system
  1102. (such as provided with Disk Manager or Norton Utilities) may help, but
  1103. the best solution (if possible) is to put all executables on a disk of
  1104. their own, protected by a hardware read-only system that sounds an
  1105. alarm if a write is attempted.
  1106.  
  1107. If you do use a resident BSI detector or a scan-while-you-copy
  1108. detector, it is important to trace back any infected diskette to its
  1109. source; the reason why viruses survive so well is that usually you
  1110. cannot do this, because the infection is found long after the
  1111. infecting diskette has been forgotten with most people's lax scanning
  1112. policies.
  1113.  
  1114. Organizations should devise and implement a careful policy, that may
  1115. include a system of vetting new software brought into the building and
  1116. free virus detectors for home machines of employees/students/etc who
  1117. take work home with them.
  1118.  
  1119. Other anti-viral techniques include:
  1120. (a) Creation of a special MBR to make the hard disk inaccessible when
  1121.     booting from a diskette (the latter is useful since booting from a
  1122.     diskette will normally bypass the protection in the CONFIG.SYS and
  1123.     AUTOEXEC.BAT files of the hard disk).  Example: GUARD.
  1124. (b) Use of Artificial Intelligence to learn about new viruses and
  1125.     extract scan patterns for them.  Examples: V-Care (CSA Interprint,
  1126.     Israel; distributed in the U.S. by Sela Consultants Corp.), Victor
  1127.     Charlie (Bangkok Security Associates, Thailand; distributed in the
  1128.     US by Computer Security Associates).
  1129. (c) Encryption of files (with decryption before execution).
  1130.  
  1131.  
  1132. D2) Is it possible to protect a computer system with only software?
  1133.  
  1134. Not perfectly; however, software defenses can significantly reduce
  1135. your risk of being affected by viruses WHEN APPLIED APPROPRIATELY.
  1136. All virus defense systems are tools - each with their own capabilities
  1137. and limitations.  Learn how your system works and be sure to work
  1138. within its limitations.
  1139.  
  1140. >From a software standpoint, a very high level of protection/detection
  1141. can be achieved with only software, using a layered approach.
  1142.  
  1143. 1)  ROM BIOS - password (access control) and selection of boot disk.
  1144.     (Some may consider this hardware.)
  1145.  
  1146. 2)  Boot sectors - integrity management and change detection.
  1147.  
  1148. 3)  OS programs - integrity management of existing programs,
  1149.     scanning of unknown programs.  Requirement of authentication
  1150.     values for any new or transmitted software.
  1151.  
  1152. 4)  Locks that prevent writing to a fixed or floppy disk.
  1153.  
  1154. As each layer is added, invasion without detection becomes more
  1155. difficult.  However complete protection against any possible attack
  1156. cannot be provided without dedicating the computer to pre-existing or
  1157. unique tasks.  The international standardization of the world on the
  1158. IBM PC architecture is both its greatest asset and its greatest
  1159. vulnerability.
  1160.  
  1161.  
  1162. D3) Is it possible to write-protect the hard disk with only software?
  1163.  
  1164. The answer is no.  There are several programs which claim to do that,
  1165. but *all* of them can be bypassed using only the currently known
  1166. techniques that are used by some viruses.  Therefore you should
  1167. never rely on such programs *alone*, although they can be useful in
  1168. combination with other anti-viral measures.
  1169.  
  1170.  
  1171. D4) What can be done with hardware protection?
  1172.  
  1173. Hardware protection can accomplish various things, including: write
  1174. protection for hard disk drives, memory protection, monitoring and
  1175. trapping unauthorized system calls, etc.  Again, no tool is foolproof.
  1176.  
  1177. The popular idea of write-protection (see D3) may stop viruses
  1178. spreading to the disk that is protected, but doesn't, in itself,
  1179. prevent a virus from running.
  1180.  
  1181. Also, some of the existing hardware protections can be easily
  1182. bypassed, fooled, or disconnected, if the virus writer knows them
  1183. well and designs a virus which is aware of the particular defense.
  1184.  
  1185.  
  1186. D5) Will setting DOS file attributes to READ ONLY protect them from
  1187.     viruses?
  1188.  
  1189. No.  While the Read Only attribute will protect your files from a few
  1190. viruses, most simply override it, and infect normally.  So, while
  1191. setting executable files to Read Only is not a bad idea, it is
  1192. certainly not a thorough protection against viruses!
  1193.  
  1194.  
  1195. D6) Will password/access control systems protect my files from
  1196.     viruses?
  1197.  
  1198. All password and other access control systems are designed to protect
  1199. the user's data from other users and/or their programs.  Remember,
  1200. however, that when you execute an infected program the virus in it
  1201. will gain your current rights/privileges.  Therefore, if the access
  1202. control system provides *you* the right to modify some files, it will
  1203. provide it to the virus too.  Note that this does not depend on the
  1204. operating system used - DOS, Unix, or whatever.  Therefore, an access
  1205. control system will protect your files from viruses no better than it
  1206. protects them from you.
  1207.  
  1208. Under DOS, there is no memory protection, so a virus could disable the
  1209. access control system in memory, or even patch the operating system
  1210. itself.  On the more advanced operating systems (Unix) this is not
  1211. possible, so at least the protection cannot be disabled by a virus.
  1212. However it will still spread, due to the reasons noted above.  In
  1213. general, the access control systems (if implemented correctly) are
  1214. able only to slow down the virus spread, not to eliminate viruses
  1215. entirely.
  1216.  
  1217. Of course, it's better to have access control than not to have it at
  1218. all.  Just be sure not to develop a false sense of security and to
  1219. rely *entirely* on the access control system to protect you.
  1220.  
  1221.  
  1222. D7) Will the protection systems in DR DOS work against viruses?
  1223.  
  1224. Partially.  Neither the password file/directory protection available
  1225. from DR DOS version 5 onwards, nor the secure disk partitions
  1226. introduced in DR DOS 6 are intended to combat viruses, but they do to
  1227. some extent.  If you have DR DOS, it is very wise to password-protect
  1228. your files (to stop accidental damage too), but don't depend on it as
  1229. the only means of defense.
  1230.  
  1231. The use of the password command (e.g. PASSWORD/W:MINE *.EXE *.COM)
  1232. will stop more viruses than the plain DOS attribute facility, but that
  1233. isn't saying much!  The combination of the password system plus a disk
  1234. compression system may be more secure (because to bypass the password
  1235. system they must access the disk directly, but under SuperStore or
  1236. Stacker the physical disk is meaningless to the virus). There may be
  1237. some viruses which, rather than invisibly infecting files on
  1238. compressed disks in fact very visibly corrupt the disk.
  1239.  
  1240. The "secure disk partitions" system introduced with DR DOS 6 may be of
  1241. some help against a few viruses that look for DOS partitions on a
  1242. disk.  The main use is in stopping people fiddling with (and
  1243. infecting) your hard disk while you are away.
  1244.  
  1245. Furthermore, DR DOS is not very compatible with MS/PC-DOS, especially
  1246. down to the low-level tricks that some viruses are using.  For
  1247. instance, some internal memory structures are "read-only" in the sense
  1248. that they are constantly updated (for DOS compatibility) but not
  1249. really used by DR DOS, so that even if a sophisticated virus modifies
  1250. them, this does not have any effect.
  1251.  
  1252. In general, using a less compatible system diminishes the number of
  1253. viruses that can infect it.  For instance, the introduction of hard
  1254. disks made the Brain virus almost disappear; the introduction of 80286
  1255. and DOS 4.x+ made the Yale and Ping Pong viruses extinct, and so on.
  1256.  
  1257.  
  1258. D8) Will a write-protect tab on a floppy disk stop viruses?
  1259.  
  1260. In general, yes.  The write-protection on IBM PC (and compatible) and
  1261. Macintosh floppy disk drives is implemented in hardware, not software,
  1262. so viruses cannot infect a diskette when the write-protection mechanism
  1263. is functioning properly.
  1264.  
  1265. But remember:
  1266.  
  1267. (a) A computer may have a faulty write-protect system (this happens!)
  1268.     - you can test it by trying to copy a file to the diskette when it
  1269.     is presumably write-protected.
  1270. (b) Someone may have removed the tab for a while, allowing a virus on.
  1271. (c) The files may have been infected before the disk was protected.
  1272.     Even some diskettes "straight from the factory" have been known to be
  1273.     infected in the production processes.
  1274.  
  1275. So it is worthwhile scanning even write-protected disks for viruses.
  1276.  
  1277.  
  1278. D9) Do local area networks (LANs) help to stop viruses or do they
  1279.     facilitate their spread?
  1280.  
  1281. Both.  A set of computers connected in a well managed LAN, with
  1282. carefully established security settings, with minimal privileges for
  1283. each user, and without a transitive path of information flow between
  1284. the users (i.e., the objects writable by any of the users are not
  1285. readable by any of the others) is more virus-resistant than the same
  1286. set of computers if they are not interconnected.  The reason is that
  1287. when all computers have (read-only) access to a common pool of
  1288. executable programs, there is usually less need for diskette swapping
  1289. and software exchange between them, and therefore less ways through
  1290. which a virus could spread.
  1291.  
  1292. However, if the LAN is not well managed, with lax security, it could
  1293. help a virus to spread like wildfire.  It might even be impossible to
  1294. remove the infection without shutting down the entire LAN.
  1295.  
  1296. A network that supports login scripting is inherently more resistant
  1297. to viruses than one that does not, if this is used to validate the
  1298. client before allowing access to the network.
  1299.  
  1300.  
  1301. D10) What is the proper way to make backups?
  1302.  
  1303. Data and text files, and programs in source form, should be backed up
  1304. each time they are modified.  However, the only backups you should
  1305. keep of COM, EXE and other *executable* files are the *original*
  1306. versions, since if you back up an executable file on your hard disk
  1307. over and over, it may have become infected meanwhile, so that you may
  1308. no longer have an uninfected backup of that file.  Therefore:
  1309.   1. If you've downloaded shareware, copy it (preferably as a ZIP or
  1310. other original archive file) onto your backup medium and do not
  1311. re-back it up later.
  1312.   2. If you have purchased commercial software, it's best to create a
  1313. ZIP (or other) archive from the original diskettes (assuming they're
  1314. not copy protected) and transfer the archive onto that medium.  Again,
  1315. do not re-back up.
  1316.   3. If you write your own programs, back up only the latest version
  1317. of the *source* programs.  Depend on recompilation to reproduce the
  1318. executables.
  1319.   4. If an executable has been replaced by a new version, then of
  1320. course you will want to keep a backup of the new version.  However, if
  1321. it has been modified as a result of your having changed configuration
  1322. information, it seems safer *not* to back up the modified file; you
  1323. can always re-configure the backup copy later if you have to.
  1324.   5. Theoretically, source programs could be infected, but until such
  1325. a virus is discovered, it seems preferable to treat such files as
  1326. non-executables and back them up whenever you modify them.  The same
  1327. advice is probably appropriate for batch files as well, despite the
  1328. fact that a few batch file infectors have been discovered.
  1329.  
  1330.  
  1331. =======================================================
  1332. = Section E.    Facts and Fibs about computer viruses =
  1333. =======================================================
  1334.  
  1335. E1) Can boot sector viruses infect non-bootable floppy disks?
  1336.  
  1337. Any diskette that has been properly formatted contains an executable
  1338. program in the boot sector.  If the diskette is not "bootable," all
  1339. that boot sector does is print a message like "Non-system disk or disk
  1340. error; replace and strike any key when ready", but it's still
  1341. executable and still vulnerable to infection.  If you accidentally
  1342. turn your machine on with a "non-bootable" diskette in the drive, and
  1343. see that message, it means that any boot virus that may have been on
  1344. that diskette *has* run, and has had the chance to infect your hard
  1345. drive, or whatever.  So when thinking about viruses, the word
  1346. "bootable" (or "non-bootable") is really misleading.  All formatted
  1347. diskettes are capable of carrying a virus.
  1348.  
  1349.  
  1350. E2) Can a virus hide in a PC's CMOS memory?
  1351.  
  1352. No.  The CMOS RAM in which system information is stored and backed up
  1353. by batteries is ported, not addressable.  That is, in order to get
  1354. anything out, you use I/O instructions.  So anything stored there is
  1355. not directly sitting in memory.  Nothing in a normal machine loads the
  1356. data from there and executes it, so a virus that "hid" in the CMOS RAM
  1357. would still have to infect an executable object of some kind in order
  1358. to load and execute whatever it had written to CMOS.  A malicious
  1359. virus can of course *alter* values in the CMOS as part of its payload,
  1360. but it can't spread through, or hide itself in, the CMOS.
  1361.  
  1362. A virus could also use the CMOS RAM to hide a small part of its
  1363. body (e.g., the payload, counters, etc.).  However, any executable
  1364. code stored there must be first extracted to ordinary memory in order
  1365. to be executed.
  1366.  
  1367.  
  1368. E3) Can a virus hide in Extended or in Expanded RAM?
  1369.  
  1370. Theoretically yes, although no such viruses are known yet.  However,
  1371. even if they are created, they will have to have a small part resident
  1372. in conventional RAM; they cannot reside *entirely* in Extended or in
  1373. Expanded RAM.
  1374.  
  1375.  
  1376. E4) Can a virus hide in Upper Memory or in High Memory?
  1377.  
  1378. Yes, it is possible to construct a virus which will locate itself
  1379. in Upper Memory (640K to 1024K) or in High Memory (1024K to 1088K),
  1380. and a few currently known viruses (e.g. EDV) do hide in Upper Memory.
  1381.  
  1382. It might be thought that there is no point in scanning in these areas
  1383. for any viruses other than those which are specifically known to
  1384. inhabit them.  However, there are cases when even ordinary viruses can
  1385. be found in Upper Memory.  Suppose that a conventional memory-resident
  1386. virus infects a TSR program and this program is loaded high by the
  1387. user (for instance, from AUTOEXEC.BAT).  Then the virus code will also
  1388. reside in Upper Memory.  Therefore, an effective scanner must be able
  1389. to scan this part of memory for viruses too.
  1390.  
  1391.  
  1392. E5) Can a virus infect data files?
  1393.  
  1394. Some viruses (e.g., Frodo, Cinderella) modify non-executable files.
  1395. However, in order to spread, the virus must be executed.  Therefore
  1396. the "infected" non-executable files cannot be sources of further
  1397. infection.
  1398.  
  1399. However, note that it is not always possible to make a sharp
  1400. distinction between executable and non-executable files.  One man's
  1401. code is another man's data and vice versa.  Some files that are not
  1402. directly executable contain code or data which can under some
  1403. conditions be executed or interpreted.
  1404.  
  1405. Some examples from the IBM PC world are .OBJ files, libraries, device
  1406. drivers, source files for any compiler or interpreter, macro files
  1407. for some packages like MS Word and Lotus 1-2-3, and many others.
  1408. Currently there are viruses that infect boot sectors, master boot
  1409. records, COM files, EXE files, BAT files, and device drivers, although
  1410. any of the objects mentioned above can theoretically be used as an
  1411. infection carrier.  PostScript files can also be used to carry a virus,
  1412. although no currently known virus does that.
  1413.  
  1414.  
  1415. E6) Can viruses spread from one type of computer to another?
  1416.  
  1417. The simple answer is that no currently known viruses can do this.
  1418. Although the disk formats may be the same (e.g. Atari ST and DOS), the
  1419. different machines interpret the code differently.  For example, the
  1420. Stoned virus cannot infect an Atari ST as the ST cannot execute the
  1421. virus code in the bootsector.  The Stoned virus contains instructions
  1422. for the 80x86 family of CPU's that the 680x0-family CPU (Atari ST)
  1423. can't understand or execute.
  1424.  
  1425. The more general answer is that such viruses are possible, but
  1426. unlikely.  Such a virus would be quite a bit larger than current
  1427. viruses and might well be easier to find.  Additionally, the low
  1428. incidence of cross-machine sharing of software means that any such
  1429. virus would be unlikely to spread -- it would be a poor environment
  1430. for virus growth.
  1431.  
  1432.  
  1433. E7) Can DOS viruses run on non-DOS machines (e.g. Mac, Amiga)?
  1434.  
  1435. In general, no.  However, on machines running DOS emulators (either
  1436. hardware or software based), DOS viruses - just like any DOS program -
  1437. may function.  These viruses would be subject to the file access
  1438. controls of the host operating system.  An example is when running a
  1439. DOS emulator such as VP/ix under a 386 UNIX environment, DOS
  1440. programs are not permitted access to files which the host UNIX system
  1441. does not allow them to.  Thus, it is important to administer these
  1442. systems carefully.
  1443.  
  1444.  
  1445. E8) Can mainframe computers be susceptible to computer viruses?
  1446.  
  1447. Yes.  Numerous experiments have shown that computer viruses spread
  1448. very quickly and effectively on mainframe systems.  However, to our
  1449. knowledge, no non-research computer virus has been seen on mainframe
  1450. systems.  (The Internet worm of November 1988 was not a computer virus
  1451. by most definitions, although it had some virus-like characteristics.)
  1452.  
  1453. Computer viruses are actually a special case of something else called
  1454. "malicious logic", and other forms of malicious logic -- notably
  1455. Trojan horses -- are far quicker, more effective, and harder to detect
  1456. than computer viruses.  Nevertheless, on personal computers many more
  1457. viruses are written than Trojans.  There are two reasons for this:
  1458. (1) Since a virus propagates, the number of users to which damage can
  1459. be caused is much greater than in the case of a Trojan; (2) It's
  1460. almost impossible to trace the source of a virus since viruses are
  1461. not attached to any particular program.
  1462.  
  1463. For further information on malicious programs on multi-user systems,
  1464. see Matt Bishop's paper, "An Overview of Malicious Logic in a Research
  1465. Environment", available by anonymous FTP on Dartmouth.edu
  1466. (129.170.16.4) as "pub/security/mallogic.ps".
  1467.  
  1468.  
  1469. E9) Some people say that disinfecting files is a bad idea.  Is that
  1470.     true?
  1471.  
  1472. Disinfecting a file is completely "safe" only if the disinfecting
  1473. process restores the non-infected state of the object completely.  That
  1474. is, not only the virus must be removed from the file, but the original
  1475. length of the file must be restored exactly, as well as its time and
  1476. date of last modification, all fields in the header, etc.  Sometimes
  1477. it is necessary to be sure that the file is placed on the same
  1478. clusters of the disk that it occupied prior to infection.  If this is
  1479. not done, then a program which uses some kind of self-checking or
  1480. copy protection may stop functioning properly, if at all.
  1481.  
  1482. None of the currently available disinfecting programs do all this.
  1483. For instance, because of the bugs that exist in many viruses, some of
  1484. the information of the original file is destroyed and cannot be
  1485. recovered. Other times, it is even impossible to detect that this
  1486. information has been destroyed and to warn the user.  Furthermore,
  1487. some viruses corrupt information very slightly and in a random way
  1488. (Nomenklatura, Phoenix), so that it is not even possible to tell which
  1489. files have been corrupted.
  1490.  
  1491. Therefore, it is usually better to replace the infected objects with
  1492. clean backups, provided you are certain that your backups are
  1493. uninfected (see D10).  You should try to disinfect files only if they
  1494. contain some valuable data that cannot be restored from backups or
  1495. compiled from their original source.
  1496.  
  1497.  
  1498. E10) Can I avoid viruses by avoiding shareware/free software/games?
  1499.  
  1500. No.  There are many documented instances in which even commercial
  1501. "shrink wrap" software was inadvertently distributed containing
  1502. viruses.  Avoiding shareware, freeware, games, etc. only isolates you
  1503. from a vast collection of software (some of it very good, some of it
  1504. very bad, most of it somewhere in between...).
  1505.  
  1506. The important thing is not to avoid a certain type of software, but to
  1507. be cautious of ANY AND ALL newly acquired software.  Simply scanning
  1508. all new software media for known viruses would be rather effective at
  1509. preventing virus infections, especially when combined with some other
  1510. prevention/detection strategy such as integrity management of
  1511. programs.
  1512.  
  1513.  
  1514. E11) Can I contract a virus on my PC by performing a "DIR" of an
  1515.      infected floppy disk?
  1516.  
  1517. If you assume that the PC you are using is virus free before you
  1518. perform the DIR command, then the answer is no.  However, when you
  1519. perform a DIR, the contents of the boot sector of the diskette are
  1520. loaded into a buffer for use when determining disk layout etc., and
  1521. certain anti-virus products will scan these buffers.  If a boot sector
  1522. virus has infected your diskette, the virus code will be contained in
  1523. the buffer, which may cause some anti-virus packages to give the
  1524. message "xyz virus found in memory, shut down computer immediately".
  1525. In fact, the virus is not a threat at this point since control of the
  1526. CPU is never passed to the virus code residing in the buffer.  But,
  1527. even though the virus is really not a threat at this point, this
  1528. message should not be ignored.  If you get a message like this, and
  1529. then reboot from a clean DOS diskette and scan your hard-drive and
  1530. find no virus, then you know that the false positive was caused by the
  1531. fact that the infected boot-sector was loaded into a buffer, and the
  1532. diskette should be appropriately disinfected before use.  The use of
  1533. DIR will not infect a clean system, even if the diskette it is being
  1534. performed on does contain a virus.
  1535.  
  1536.  
  1537. E12) Is there any risk in copying data files from an infected floppy
  1538.     disk to a clean PC's hard disk?
  1539.  
  1540. Assuming that you did not boot or run any executable programs from the
  1541. infected disk, the answer is generally no.  There are two caveats: 1)
  1542. you should be somewhat concerned about checking the integrity of these
  1543. data files as they may have been destroyed or altered by the virus,
  1544. and 2) if any of the "data" files are interpretable as executable by
  1545. some other program (such as a Lotus macro) then these files should be
  1546. treated as potentially malicious until the symptoms of the infection
  1547. are known.  The copying process itself is safe (given the above
  1548. scenario).  However, you should be concerned with what type of files
  1549. are being copied to avoid introducing other problems.
  1550.  
  1551.  
  1552. E13) Can a DOS virus survive and spread on an OS/2 system using the
  1553.      HPFS file system?
  1554.  
  1555. Yes, both file-infecting and boot sector viruses can infect HPFS
  1556. partitions.  File-infecting viruses function normally and can activate
  1557. and do their dirty deeds, and boot sector viruses can prevent OS/2
  1558. from booting if the primary bootable partition is infected.  Viruses
  1559. that try to directly address disk sectors cannot function because OS/2
  1560. prevents this activity.
  1561.  
  1562.  
  1563. E14) Under OS/2 2.0, could a virus infected DOS session infect another
  1564.     DOS session?
  1565.  
  1566. Each DOS program is run in a separate Virtual DOS Machine (their
  1567. memory spaces are kept separated by OS/2).  However, any DOS program
  1568. has almost complete access to the files and disks, so infection can
  1569. occur if the virus infects files; any other DOS session that executes
  1570. a program infected by a virus that makes itself memory resident would
  1571. itself become infected.
  1572.  
  1573. However, bear in mind that all DOS sessions share the same copy of the
  1574. command interpreter.  Hence if it becomes infected, the virus will be
  1575. active in *all* DOS sessions.
  1576.  
  1577.  
  1578. E15) Can normal DOS viruses work under MS Windows?
  1579.  
  1580. Most of them cannot.  A system that runs exclusively MS Windows is,
  1581. in general, more virus-resistant than a plain DOS system.  The reason
  1582. is that most resident viruses are not compatible with the memory
  1583. management in Windows.  Furthermore, most of the existing viruses will
  1584. damage the Windows applications if they try to infect them as normal
  1585. EXE files.  The damaged applications will stop working and this will
  1586. alert the user that something is wrong.
  1587.  
  1588. However, virus-resistant is by no means virus-proof.  For instance,
  1589. most of the well-behaved resident viruses that infect only COM files
  1590. (Cascade is an excellent example), will work perfectly in a DOS
  1591. window.  All non-resident COM infectors will be able to run and infect
  1592. too.  And currently there exists at least one Windows-specific virus
  1593. which is able to properly infect Windows applications (it is
  1594. compatible with the NewEXE file format).
  1595.  
  1596. Any low level trapping of Interrupt 13, as by resident boot sector and
  1597. MBR viruses, can also affect Windows operation, particularly if
  1598. protected disk access (32BitDiskAccess=ON in SYSTEM.INI) is used.
  1599.  
  1600.  
  1601. =========================================
  1602. = Section F.    Miscellaneous Questions =
  1603. =========================================
  1604.  
  1605. F1) How many viruses are there?
  1606.  
  1607. It is not possible to give an exact number because new viruses are
  1608. being created literally every day.  Furthermore, different anti-virus
  1609. researchers use different criteria to decide whether two viruses are
  1610. different or one and the same.  Some count viruses as different if
  1611. they differ by at least one bit in their non-variable code.  Others
  1612. group the viruses in families and do not count the closely related
  1613. variants in one family as different viruses.
  1614.  
  1615. Taking a rough average, as of October 1992 there were about 1,800 IBM
  1616. PC viruses, about 150 Amiga viruses, about 30 Macintosh viruses, about
  1617. a dozen Acorn Archimedes viruses, several Atari ST viruses, and a few
  1618. Apple II viruses.
  1619.  
  1620. However, very few of the existing viruses are widespread.  For
  1621. instance, only about three dozen of the known IBM PC viruses are
  1622. causing most of the reported infections.
  1623.  
  1624.  
  1625. F2) How do viruses spread so quickly?
  1626.  
  1627. This is a very complex issue.  Most viruses don't spread very quickly.
  1628. Those that do spread widely are able to do so for a variety of
  1629. reasons.  A large target population (i.e., millions of compatible
  1630. computers) helps...  A large virus population helps...  Vendors whose
  1631. quality assurance mechanisms rely on, for example, outdated scanners
  1632. help...  Users who gratuitously insert new software into their systems
  1633. without making any attempt to test for viruses help...  All of these
  1634. things are factors.
  1635.  
  1636.  
  1637. F3) What is the plural of "virus"?  "Viruses" or "viri" or "virii" or...
  1638.  
  1639. The correct English plural of "virus" is "viruses."  The Latin word is
  1640. a mass noun (like "air"), and there is no correct Latin plural.
  1641. Please use "viruses," and if people use other forms, please don't use
  1642. VIRUS-L/comp.virus to correct them.
  1643.  
  1644.  
  1645. F4) When reporting a virus infection (and looking for assistance), what
  1646.     information should be included?
  1647.  
  1648. People frequently post messages to VIRUS-L/comp.virus requesting
  1649. assistance on a suspected virus problem.  Quite often, the information
  1650. supplied is not sufficient for the various experts on the list to be
  1651. able to help out.  Also note that any such assistance from members of
  1652. the list is provided on a volunteer basis; be grateful for any help
  1653. received.  Try to provide the following information in your requests
  1654. for assistance:
  1655.         - The name of the virus (if known);
  1656.         - The name of the program that detected it;
  1657.         - The version of the program that detected it;
  1658.         - Any other anti-virus software that you are running and
  1659. whether it has been able to detect the virus or not, and if yes, by
  1660. what name did it call it;
  1661.         - Your software and hardware configuration (computer type,
  1662. kinds of disk(ette) drives, amount of memory and configuration
  1663. (extended/expanded/conventional), TSR programs and device drivers
  1664. used, OS version, etc.)
  1665.  
  1666. It is helpful if you can use more than one scanning program to
  1667. identify a virus, and to say which scanner gave which identification.
  1668. However, some scanning programs leave "signatures" in memory which
  1669. will confuse others, so it is best to do a "cold reboot" between runs
  1670. of successive scanners, particularly if you are getting confusing
  1671. results.
  1672.  
  1673.  
  1674. F5) How often should we upgrade our anti-virus tools to minimize
  1675.     software and labor costs and maximize our protection?
  1676.  
  1677. This is a difficult question to answer.  Antiviral software is a kind
  1678. of insurance, and these type of calculations are difficult.
  1679.  
  1680. There are two things to watch out for here: the general "style" of the
  1681. software, and the signatures which scanners use to identify viruses.
  1682. Scanners should be updated more frequently than other software, and it
  1683. is probably a good idea to update your set of signatures at least once
  1684. every two months.
  1685.  
  1686. Some antiviral software looks for changes to programs or specific
  1687. types of viral "activity," and these programs generally claim to be
  1688. good for "all current and future viral programs."  However, even these
  1689. programs cannot guarantee to protect against all future viruses, and
  1690. should probably be upgraded once per year.
  1691.  
  1692. Of course, not every anti-virus product is effective against all
  1693. viruses, even if upgraded regularly.  Thus, do *not* depend on the
  1694. fact that you have upgraded your product recently as a guarantee that
  1695. your system is free of viruses!
  1696.  
  1697.  
  1698. =====================================================================
  1699. = Section G.    Specific Virus and Anti-viral software Questions... =
  1700. =====================================================================
  1701.  
  1702.  
  1703. G1) I was infected by the Jerusalem virus and disinfected the infected
  1704.     files with my favorite anti-virus program.  However, Wordperfect
  1705.     and some other programs still refuse to work.  Why?
  1706.  
  1707. The Jerusalem virus and WordPerfect 4.2 program combination is an
  1708. example of a virus and program that cannot be completely disinfected
  1709. by an anti-virus tool.  In some cases such as this one, the virus will
  1710. destroy code by overwriting it instead of appending itself to the
  1711. file.  The only solution is to re-install the programs from clean
  1712. (non-infected) backups or distribution media.  (See question D10.)
  1713.  
  1714.  
  1715. G2) I was told that the Stoned virus displays the text "Your PC is now
  1716.     Stoned" at boot time.  I have been infected by this virus several
  1717.     times, but have never seen the message.  Why?
  1718.  
  1719. The "original" Stoned message was ".Your PC is now Stoned!", where the
  1720. "." represents the "bell" character (ASCII 7 or "PC speaker beep").
  1721. The message is displayed with a probability of 1 in 8 only when a PC is
  1722. booted from an infected diskette.  When booting from an infected hard
  1723. disk, Stoned never displays this message.
  1724.  
  1725. Recently, versions of Stoned with no message whatsoever or only the
  1726. leading bell character have become very common.  These versions of
  1727. Stoned are likely to go unnoticed by all but the most observant, even
  1728. when regularly booting from infected diskettes.
  1729.  
  1730. Contrary to some reports, the Stoned virus -does NOT- display the
  1731. message "LEGALISE MARIJUANA", although such a string is quite clearly
  1732. visible in the boot sectors of diskettes infected with the "original"
  1733. version of Stoned in "standard" PC's.
  1734.  
  1735.  
  1736. G3) I was infected by both Stoned and Michelangelo.  Why has my
  1737.     computer became unbootable?  And why, each time I run my favorite
  1738.     scanner, does it find one of the viruses and say that it is
  1739.     removed, but when I run it again, it says that the virus is still
  1740.     there?
  1741.  
  1742. These two viruses store the original Master Boot Record at one and the
  1743. same place on the hard disk.  They do not recognize each other, and
  1744. therefore a computer can become infected with both of them at the same
  1745. time.
  1746.  
  1747. The first of these viruses that infects the computer will overwrite
  1748. the Master Boot Record with its body and store the original MBR at a
  1749. certain place on the disk.  So far, this is normal for a boot-record
  1750. virus.  But if now the other virus infects the computer too, it will
  1751. replace the MBR (which now contains the virus that has come first)
  1752. with its own body, and store what it believes is the original MBR (but
  1753. in fact is the body of the first virus) AT THE SAME PLACE on the hard
  1754. disk, thus OVERWRITING the original MBR.  When this happens, the
  1755. contents of the original MBR are lost.  Therefore the disk becomes
  1756. non-bootable.
  1757.  
  1758. When a virus removal program inspects such a hard disk, it will see
  1759. the SECOND virus in the MBR and will try to remove it by overwriting
  1760. it with the contents of the sector where this virus normally stores
  1761. the original MBR.  However, now this sector contains the body of the
  1762. FIRST virus.  Therefore, the virus removal program will install the
  1763. first virus in trying to remove the second.  In all probability it
  1764. will not wipe out the sector where the (infected) MBR has been stored.
  1765.  
  1766. When the program is run again, it will find the FIRST virus in the
  1767. MBR.  By trying to remove it, the program will get the contents of the
  1768. sector where this virus normally stores the original MBR, and will
  1769. move it over the current (infected) MBR.  Unfortunately, this sector
  1770. still contains the body of the FIRST virus.  Therefore, the body of
  1771. this virus will be re-installed over the MBR ad infinitum.
  1772.  
  1773. There is no easy solution to this problem, since the contents of the
  1774. original MBR is lost.  The only solution for the anti-virus program is
  1775. to detect that there is a problem, and to overwrite the contents of
  1776. the MBR with a valid MBR program, which the anti-virus program will
  1777. have to carry with itself.  If your favorite anti-virus program is not
  1778. that smart, consider replacing it with a better one, or just boot from
  1779. a write-protected uninfected DOS 5.0 diskette, and execute the program
  1780. FDISK with the option /MBR.  This will re-create the executable code
  1781. in the MBR without modifying the partition table data.
  1782.  
  1783. In general, infection by multiple viruses of the same file or area is
  1784. possible and vital areas of the original may be lost.  This can make
  1785. it difficult or impossible for virus disinfection tools to be
  1786. effective, and replacement of the lost file/area will be necessary.
  1787.  
  1788. ====================
  1789. [End of VIRUS-L/comp.virus FAQ]
  1790.  
  1791. ------------------------------
  1792.  
  1793. End of VIRUS-L Digest [Volume 5 Issue 184]
  1794. ******************************************
  1795.  
  1796.  
  1797.